home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19970626-19970929
/
000412_news@newsmaster….columbia.edu _Fri Sep 26 14:09:28 1997.msg
< prev
next >
Wrap
Internet Message Format
|
1997-09-28
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA23375
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 26 Sep 1997 14:09:28 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA11682
for kermit.misc@watsun; Fri, 26 Sep 1997 14:09:27 -0400 (EDT)
Path: news.columbia.edu!news.new-york.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-was.dfn.de!news-kar1.dfn.de!news-stu1.dfn.de!news-mue1.dfn.de!news-nue1.dfn.de!uni-erlangen.de!rznews.rrze.uni-erlangen.de!cip.informatik.uni-erlangen.de!mskuhn
From: mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn)
Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems,comp.std.internat
Subject: Re: Kermit as a terminal for V.18-capable modems
Date: 26 Sep 1997 09:50:49 GMT
Organization: Student Pool, CSD., University of Erlangen
Lines: 45
Message-ID: <60g0hp$8bs$1@rznews.rrze.uni-erlangen.de>
References: <609at2$jf1@gateway.dircsa.org.au>
Reply-To: mskuhn@cip.informatik.uni-erlangen.de
NNTP-Posting-Host: mskuhn@faui04d.informatik.uni-erlangen.de
Xref: news.columbia.edu comp.protocols.kermit.misc:7737 comp.dcom.modems:200736 comp.std.internat:7180
arthur@gateway.dircsa.org.au (Arthur Marsh) writes:
>This is interesting as I have not previously seen any modem explicitly
>supporting double byte character sets, and wonder how an external
>V.18-compliant modem would do so, and what non-propriatary-to-the-V.18
>-compliant modem terminal software e.g. Kermit-95 would do to handle double
>byte character sets, given that modems currently use 8 data bits 1 stop bits
>no parity for commands and responses.
RS-232 links typically have an 8-bit framing structure. Therefore, you
have reliable byte synchonization, but if your characters are 16-bit
long and represented as two bytes, then a single lost character can
mess up your synchronization. Therefore, using raw UCS-2 on async serial
PC ports is a very bad idea.
Possible solutions:
- Use 16-bit framing. Bad, because no common UART today supports this,
they all only to 5-8 bit framing.
- Use an error correction protocol like HDLC to preserve block synchronization.
This is probably overkill.
- Use educated guess resynchronization based on unassigned UCS-2 bytes
that indicate a desynchronization state. Ugly hack.
- Use UTF-8. It is self synchronizing, ASCII compatible, and therefore
clearly the nicest solution.
I recently discussed UTF-8 support with a Kermit author and he seems to
have put it on his todo list. Mail him that you would also be interested.
>Is there a standard sequence in ISO 10646 that can be used to tell a terminal
>package to enter ISO 10646 mode? Presumably the V.18-compliant modem could
>also accept and send data as single-byte Latin-1 characters.
ESC % G announces UTF-8. See the ISO 10646 standard and the UTF-8
addendum for all the ISO 2022 ESC sequences if you really need switching
(section R.6).
Check out <ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/> for
more info about UTF-8.
Markus